Conversation
This client was written against ABI 0.12 and the engine has moved twice since. The whole of the gap is three symbols, and both of them that matter bite a program that does nothing unusual: a byte string cell made Type.of throw rather than answer, and a node carried a table id that nothing here could turn into a name. ZU_TYPE_BYTES is a type of its own rather than a string that happens to hold octets, so this adds Value.Bytes, Type.BYTES and Row.getBytes rather than widening Value.Str. A host that took the octets for a string would decode them, and octets that are not UTF-8 do not survive that. Value.Bytes writes out equals, hashCode and toString because a record over an array compares by identity otherwise, and two byte strings holding the same octets are one value. It spells itself in hex, which is how the engine and the corpus both write one. zu_conn_table_name is what turns the number in a Value.Node into the name the statement wrote. Node and rel tables share one id space so one call answers for both kinds, and an id no table has comes back null rather than throwing, because asking is how a host finds out. Both providers carry both calls: the FFM side gets two more handles in Abi and two overrides, the JNI side two natives, two shims and two more lines in the registration table. The TCK covers them, so what is checked is that the two providers agree rather than that one of them works. api/surface.txt is every addition and no removal, which is a minor release.
The header this client vendors is now the engine's header byte for byte, which is what CI has been checking all along and what nothing has satisfied since the check was added. Catching up to the file rather than to the version turned up four exported functions the version does not mention. zu_error_subject_kind, zu_error_subject, zu_error_graph and zu_error_schema arrived in tamnd/zu#581 with ZU_ABI_VERSION left at 0.14, though the two commits before it did bump. So reading the macro was never going to find them and diffing the file was. I have filed that against the engine as tamnd/zu#697. The four carry what ISO 39075 subclause 23.2 asks a diagnostic record to name: which thing the condition is about, what it is called, and the graph and schema the statement was running in. The kind is kept as its own word rather than glued to the front of the name, so asking whether a failure is about a label is one string compared against one word, and an editor that wants to underline the name gets the name with nothing around it. Both providers bind all four, and both TCK suites pass against a real engine: 209 cases through Panama, 211 through JNI, 44 in the core, no failures. This changes the shape of two public members rather than only adding to them. Diagnostic gains four components, so its canonical constructor and its of factory both take fifteen arguments where they took eleven. By the rule in README, a name that changes shape is a major release. Both are the provider-facing way to build a record, so the callers this breaks are provider implementations rather than programs that read rows, but it breaks them and the surface file says so. ZuException gains four accessors and Diagnostic four component readers, and those are additions.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This client was written against ABI 0.12 and the engine has moved twice since. The whole of the gap is three additions to
zu.h, and both of the ones that matter bite a program that does nothing unusual: a byte string cell madeType.ofthrow rather than answer, and a node carried a table id that nothing here could turn into a name.ZU_TYPE_BYTESis a type of its own rather than a string that happens to hold octets, so this addsValue.Bytes,Type.BYTESandRow.getBytesrather than wideningValue.Str. A host that took the octets for a string would decode them, and octets that are not UTF-8 do not survive that.Value.Byteswrites outequals,hashCodeandtoStringbecause a record over an array compares by identity otherwise, and two byte strings holding the same octets are one value. It spells itself in hex, which is how the engine and the corpus both write one.zu_conn_table_nameis what turns the number in aValue.Nodeinto the name the statement wrote, and it is what a corpus runner needs to spell a node asperson#1. Node and rel tables share one id space so one call answers for both kinds, and an id no table has comes back null rather than throwing, because asking is how a host finds out. The doc onValue.Node.table()said the C ABI had no such call, which is no longer true, so it now points atConnection.tableName.Both providers carry both calls. The FFM side gets two more handles in
Abiand two overrides inFfmBinding;utf8is now written over a sharedoctetshelper so the byte path and the string path copy the same way. The JNI side gets two natives, two shims, two lines in theZU_SYMBOLStable and two in the registration table.api/surface.txtis every addition and no removal, which is a minor release.What was run
On a Linux host with JDK 25 and a
libzuat the current engine revision, both providers, the whole TCK:zudb-ffm: 209 tests, 0 failureszudb-jni: 211 tests, 0 failuresThat includes the 9 new
BytesTestcases and the 3 newTableNameTestcases on each provider, so what is checked is that the two agree rather than that one of them works.scripts/build-shim.shbuilds the C shim clean, and the Java compiles under-Xlint:all -Werroras everything here does.